perm filename PROTOC.PUB[DLN,MRC]5 blob
sn#428669 filedate 1979-03-17 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00018 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00003 00002 .DEVICE XGP
C00004 00003 %5First Edition
C00005 00004 .S Conventions
C00007 00005 .S Preface
C00011 00006 .S Host-Host Protocol
C00019 00007 The algorithm is: (all numbers should be read as octal)
C00020 00008 There is always at least one word in the data part of the packet. The
C00023 00009 %6←Packet Format
C00026 00010 %6←Host-Host Opcodes%1
C00032 00011 %6←Connections%1
C00035 00012 .S Introduction to Tertiary Protocols
C00038 00013 .S File Transfer Protocol
C00044 00014 %6←FTP Replies%1
C00047 00015 %6←Access Control Commands%1
C00051 00016 %6←The DATA Command%1
C00057 00017 %6←FTP Service Commands%1
C00066 00018 .S Glossary
C00073 ENDMK
C⊗;
.DEVICE XGP
.FONT 1 "BASL30";
.FONT 2 "BASI30";
.FONT 3 "BUCK75";
.FONT 4 "CRTURZ";
.FONT 5 "BAXL40";
.FONT 6 "BAXI35";
.FONT 7 "FIX25";
.AT "ffi" ⊂ IF THISFONT ≤ 2 THEN "≠" ELSE "fαfαi" ⊃;
.AT "ffl" ⊂ IF THISFONT ≤ 2 THEN "α∞" ELSE "fαfαl" ⊃;
.AT "ff" ⊂ IF THISFONT ≤ 2 THEN "≥" ELSE "fαf" ⊃;
.AT "fi" ⊂ IF THISFONT ≤ 2 THEN "α≡" ELSE "fαi" ⊃;
.AT "fl" ⊂ IF THISFONT ≤ 2 THEN "∨" ELSE "fαl" ⊃;
.PAGE FRAME 53 HIGH 80 WIDE;
.!XGPLFTMAR←216;
.TURN ON "←{%α"
.MACRO S(TIT); ⊂ NEXT PAGE; ONCE CENTER; SEC←NULL;
%6TIT
.SKIP; SEC←"TIT";
.⊃
%5First Edition
.SKIP 3
%4←C
.SKIP 1
%3←DIALNET PROTOCOLS
.SKIP 1
%2←Mark Crispin %1and %2Ignacio Zabala%1
.SKIP 10
.INDENT 5
These protocols are being developed as part of the %2Dialnet%1 project
at the Stanford University Artificial Intelligence Laboratory supported by
NSF grant MCS 77-02080 with John McCarthy as Principal Investigator. The
project is described in a paper available online at Arpanet host SU-AI as
DIALNE[DIA,JMC].
This is PROTOC.PUB[DLN,MRC] at Arpanet host SU-AI (octal 13, decimal 11.).
.EVERY HEADING({sec},%2Dialnet Protocols%1,{DATE})
.EVERY FOOTING(,{PAGE},)
.S Conventions
All numbers without an explicit base (ie, octal or decimal) specified
should be interpreted as octal unless the number is immediately followed
by a dot, in which case it is decimal.
All three-digit octal numbers should be interpreted as representing an
8.-bit byte, with bits right-justified within the number (ie, from 000 to
377). Bytes are expressed in the form as returned by the modem (ie, lsb
first in the data stream).
All six-digit octal numbers should be interpreted as representing a
16.-bit double-byte, with bits right-justified within the number (ie, from
000000 to 177777). Double-bytes are expressed in the form returned by the
modem (ie, low order byte and lsb first); ie, 010041 is transmitted as
041 020.
.S Preface
%2←"Aren't you glad you use Dialnet? Don't you wish everybody did?"%1
%2Dialnet%1 provides a capability for geographically separated computers,
called %2hosts%1, to communicate with each other. The host computers
typically differ from one another in type, speed, word length, operating
system, etc. Each computer utilizes %2Dialnet%1 via ordinary phone lines
and special modems.
As in many other data communication schemes, a layered approach has been
selected in the design of the Dialnet protocols. Each layer sees the
immediate lower layer as a "black box" and need not be concerned about its
internal structure. The lowest layer is the line protocol of the
modems, which transfers data bytes over the phone lines and does necessary
byte framing, but otherwise has no error correction facilities. At this
writing, the modem type used are VADIC VA3405 1200/1200 baud full duplex
asyncronous modems.
Next is the %2host-host%1 layer, which breaks the data stream into chunks,
or %2packets%1. Each packet is checksummed and sequenced, so that
retransmission can be done on a packet whose previous transmission was
corrupted in some way. Many systems may want to implement this layer in
their operating system, so all %2Dialnet%1 user programs will behave at
this level in the same manner.
Finally comes the user-level protocols. This includes file transfer,
mail, linking, telnetting, etc. These are user-level programs, and %2Dialnet%1
has been designed with enough flexibility to allow for users to create
private protocols of their own.
Questions concerning %2Dialnet%1 protocols should be addressed to:
.SKIP
.BEGIN NOFILL
%2←Mark Crispin
←Artificial Intelligence Laboratory
←Stanford, California 94305
.SKIP
←Phone: (415) 491-4712
←Arpanet: MRC@SU-AI%1
.END
Copies of all correspondence should be sent to John McCarthy and Les
Earnest at the above US mail address or via Arpanet mail to JMC@SU-AI and
LES@SU-AI.
It is the author's intent that these protocols are both simple in their
implementation and powerful in their operation. Certainly a major design
consideration was to design protocols that ordinary mortals could
implement on their systems.
.S Host-Host Protocol
All data is sent in the form of packets, which contain a %2packet
header%1, optional %2data%1, and a %2packet trailer%1. The packet header
serves to identify the type of packet, the size of the data area and
provides information necessary for data flow and error correction. The
packet trailer provides a checksum for the packet. Packets are framed at
each end with a %2start of packet%1 and an %2end of packet%1 marker.
The bytes which indicate start of packet are called SOP, and consist of
ASCII DLE (220) followed by STX (202); similarly, the bytes which indicate
end of packet are called EOP, and are ASCII DLE followed by ETX (203).
Note that the 200 bit is %2on%1 in DLE, STX, and ETX. If a 220 byte is to
be sent, it is quoted by being sent twice. DLE followed by anything other
than STX, ETX, or DLE is currently undefined; any such combination when
received should be discarded. 020, 002, and 003 are %2not%1 considered to
be DLE, STX, and ETX.
There are two types of packets in %2Dialnet%1: %2controlled%1 and
%2uncontrolled%1 packets.
Controlled packets have a packet number, which starts at 001 and is
incremented with each packet sent. The packet number wraps around to 001
from 377. Up to two (the default window size) packets may be sent before
an acknowledgement is received for (at least) the first packet. The
window begins with the first unacknowledged packet; therefore the window
size is an allocation which is used up as packets are sent and is given
back as packets are acknowledged.
Uncontrolled packets (ie, NOP, NAK, and ERR) have a packet number of 000.
These packets do not count against the window, and are not remembered for
retransmission after they are sent. Therefore they are lost if an error
occurs while they are being transmitted. This is because what information
they convey is generally timing-critical; if the packet was lost nothing
would be gained by sending it again.
It is a packet number of 000 and not the opcode which specifies a packet
as being controlled or uncontrolled. However, it is a safe generalization
to state that NOP, NAK, and ERR are "always" uncontrolled and the other
opcodes are "always" controlled.
A properly received controlled packet must be acknowledged for the sender
to know that the receiver successfully received the packet and to release
that packet from the window. Each packet has an acknowledgement byte
which is used for this purpose. This byte in a packet sent by the
receiver contains the number of the highest successfully received packet.
Acknowledging a packet implies acknowledging all unacknowledged packets
with lower packet numbers, therefore a successfully received packet can
merely set the acknowledgement byte for the next packet to be sent without
actually forcing a packet to be sent.
Controlled packets must be received in sequence. If the receiver receives
a packet it has already acknowledged it should discard it. Packets which
have a sequence number higher than the expected packet and packets with
incorrect checksum should be discarded, and a NAK sent for the expected
packet. In the event of a framing error, the receiver should discard all
input until an SOP is encountered in the input stream. If a packet is
discarded for being out of sequence, its acknowledgement byte should still
be processedd, otherwise an acknowledgement may be unnecessarily missed.
If a host has nothing to transmit at the current time, it is recommended
that it send a NOP, repeated every five seconds or so. This not only
keeps this part of the data link up, but also assures that the receiver is
continuing to receive up to date acknowledgements. However, if the sender
has packets waiting to be acknowledged, it should retransmit the last
packet on the acknowledgement pending list. This is to avoid a possible
deadlock which occurs when the last packet before the sending goes idle is
lost.
In %2Dialnet%1, the window is %2optional%1; in particular, an
implementation which uses the window should not get upset because the
foreign host disobeys it (it can of course neglect to acknowledge packets
which cause data overruns and force them to be retransmitted). However,
any implementation which is trying to be reasonably efficient should do
something about handling windows and telling the foreign host what sort of
window size it can live with.
There is no official timeout for deciding whether a host is still alive or
whether the phone connection is poor enough to be unusable. Each
implementor must decide these for him/herself.
The packet checksum algorithm used is the result of a conversation with
Knuth. The checksum is 16. bits long and all of the packet header
variables and the entire data area. It does NOT include the packet
trailer or the SOP/EOP packet framing codes. Note that framing checks
happen %2before%1 the checksum check.
The algorithm is: (all numbers should be read as octal)
.SKIP
.BEGIN NOFILL INDENT 5
checksum := 1;
while newchar do
checksum := (checksum * 013215 + newchar) & 177777;
.END
In PDP-10 assembly code, this would be:
.SKIP
.BEGIN NOFILL
%7
; CHKBYT adds a byte to the checksum in SUM.
; At the beginning of each packet SUM is
; initialized to 1.
; Call: MOVE CHR,<byte from data stream>
; PUSHJ P,CHKBYT
; <return>
CHKBYT: IMULI SUM,013215
ADDI SUM,(CHR)
ANDI SUM,177777
POPJ P,
.END
There is always at least one word in the data part of the packet. The
data part size refers to the number of %2additional%1 words in the data
part. Hence the data part can be %2from 1 to 256%1 data bytes long.
This means that the "data size" field in the packet header is actually
%2one less%1 than the actual data size.
The motivation for this is that a power of two is a convenient unit of
storage for many systems. In addition, many implementations will find it
convenient to pack four data bytes in a single storage word. With framing
and DLE doubling stripped, this means that the packet header will be
exactly one storage word, and the data part will begin on a storage word
boundary. In addition, the data part of a maximum-size packet will also
end on a storage word. This is significant for many systems in terms of
buffering; whether a byte-by-byte copy must be done or a faster word
transfer.
In the CLS, NAK, EOF, and INT op-codes the data byte is meaningless and
should be ignored, however, it still must be present. Additionally,
this byte should always be zero, to allow these opcodes to have a
meaningful data part in a future revision of the protocol.
There are no restrictions on the size or content of the data part of a
NOP packet, except the packet structure restriction that 1≤size≤256.
Since, however, the data is ignored by the receiver, a NOP packet would
generally have a one-byte data part, although some systems might want
to pad to 4 data bytes (note that this means the size field in the packet
header is 3!) to keep things on word boundaries.
.NEXT PAGE
%6←Packet Format
%7
.BEGIN NOFILL
←________________________________________
←| |
←| 2 bytes SOP framing mark |
←| |
←|======================================|
←| Channel # | Opcode |
←| (4 bits) | (4 bits) |
←|__________________|___________________|
←| Mpx channel | Packet number |
←| (3 bits) | (5 bits) |
←|______________|_______________________|
←| Reserved | Acknowledgement |
←| (3 bits) | (5 bits) |
←|______________|_______________________|
←| |
←| 1 byte Data size |
←|======================================|
←| |
←| 1 byte Data word |
←|______________________________________|
←| |
←| (specified |
←| by data Additional data bytes |
←| size byte) |
←| |
←|======================================|
←| |
←| 2 bytes Packet checksum |
←| |
←|======================================|
←| |
←| 2 bytes EOP framing mark |
←| |
←|______________________________________|
%1
.END
.NEXT PAGE
%6←Host-Host Opcodes%1
In the descriptions below, certain arguments are passed along with the
commands. These arguments are listed in the order in which they occur,
along with their byte size. They all occur in the DATA field of the
packet.
00 NOP (No-op)
This opcode is a no-operation and should be ignored by the receiver
except that the packet header still has significant information (ie,
the acknowledgement byte). It is used to acknowledge a packet without
doing anything else.
.IF LINES<10 THEN NEXT PAGE;
01 RPC (Request Process Connection)
.BREAK
.BEGIN INDENT 10 NOFILL
(optional) 8 bytes of process ID
(optional) 1 byte of initial window size
.END
This is the establish connection opcode. It serves a dual purpose;
to request establishing a connection, and to confirm establishing a
connection. In the first case, the data area contains an 8.-byte %2process
ID%1, which is a handle to the remote process the sender wishes to connect
to. In the latter case, no process ID is specified. A single byte
may follow the process ID to specify an initial window size.
.IF LINES<10 THEN NEXT PAGE;
02 CLS (Close Connection)
This is the terminate connection opcode. It may either terminate
an existing connection or abort a request for one.
.IF LINES<10 THEN NEXT PAGE;
03 WIN (set WINdow size)
.BREAK
.BEGIN INDENT 10 NOFILL
1 byte of window size
.END
This opcode sets the input window size; ie, it suggests to the receiver
how many packets it may send before waiting for an acknowledgement. The
minimum (and default) window size is 2 packets. The absolute maximum
window is 15.; however, many systems may want to set a smaller maximum
window. At Stanford, the system maximum is 5 packets.
.IF LINES<10 THEN NEXT PAGE;
04 MSG (MeSsaGe)
.BREAK
.BEGIN INDENT 10 NOFILL
1 to 256. bytes of data
.END
This is the data transmission opcode. The contents of the data
part are passed to the tertiary process.
.IF LINES<10 THEN NEXT PAGE;
05 NAK (Negative AcKnowledgment)
This opcode requests that the receiver retransmit all unacknowledged
packets that it sent.
.IF LINES<10 THEN NEXT PAGE;
06 EOF (End Of File)
This opcode is used to raise an "end of file" condition on a particular
channel to indicate the end of a data stream. The interpretation of
"end of file" is defined by the high-level protocol using it.
.IF LINES<10 THEN NEXT PAGE;
07 INT (Interrupt)
This opcode is used to raise an "interrupt" condition on a particular
channel. The user process should be told of the interrupt immediately;
if a data mark is needed in the data stream the high-level protocol
should perform this function. The interpretation of "interrupt" is
defined by the high-level protocol using it.
.IF LINES<10 THEN NEXT PAGE;
10 ERR (Error)
.BREAK
.BEGIN INDENT 10 NOFILL
1 to 256. bytes of ASCII error text
.END
This opcode is used to send a protocol error warning. It is intended that
a receiver of such a warning output the contents of the data part of the
message (which should be an ASCII string) on a logging terminal so that
the support staff can determine the cause of the problem and take corrective
action. This opcode should be used judiciously, since needless usage would
only defeat its purpose.
.NEXT PAGE
%6←Connections%1
In the discussion below, U refers to the process which initially provoked
the connection or %2user%1, S refers to the the process passively waiting
for a connection or %2server%1.
Channel 0 is to be used for ICP.
Following the establishment of a dialup connection, U should send a few
NOP's to S to avoid possible problems with dropped bytes while connecting.
U must know the process ID of the S it wants to connect to. As far as
Dialnet is concerned, process ID's are arbitrary ASCII strings. However,
conventions have been established as noted elsewhere.
U sends an RPC with the process ID at S it wants to connect to. S may
have been waiting for a connection, or perhaps was created by S's host as
a result of the RPC. If S does not exist or S's host is unable or
unwilling to make the connection at the present time, S's host should
return a CLS to refuse the connection.
Otherwise, S accepts the connection by sending an RPC back to U, with a
null process ID. The connection has now been established, and the process
ID is no longer used by the host-host protocol. The two processes may now
pass data back and forth using the various Host-Host opcodes.
When a host wishes to terminate a connection, it sends a CLS. Once a CLS
has been sent, no further MSG's may be sent and any MSG sent should be
replied to with an ERR. Of course, a new connection may be established
with RPC. Breaking the phone connection implies terminating the
connection.
When a connection is terminated, the recepient of the CLS should send a
CLS to confirm terminating the process.
.S Introduction to Tertiary Protocols
All protocol communication in the higher level Dialnet protocols (e.g.
MAIL, File Transfer) uses a list format for messages. Each message
therefore has the form
(<identifier> <item> ... <item>)
where the items themselves are either identifiers or have a similar
structure. The object of this scheme is to ensure flexibility.
Suppose, for example, that one of the items in a protocol message
designates a user name. Initial designs of Dialnet may allow only a
character string without parentheses like SMITH to designate the user.
Later this might be elaborated to also allow a complex designator like
(SUCCESSOR SMITH) to designate the person who has replaced SMITH in this
job assignment.
There is no present intention that the Dialnet protocols will be subject
to rapid elaboration. The present object is merely to build these
protocols so that they will not be subject to blind alleys. Therefore,
there are no fixed size fields, and item that is initially represented by
an atomic name may later be replaced by some kind of expression, and new
terms may be adjoined to lists. Thus if an item is presently denoted by a
three term list, an elaborated protocol may later call for a four item
list, but if the same initial identifier is used, it should still be
possible for a recipient to ignore the fourth item and still use the
message.
We believe that these conventions, at slight cost in initial
implementation, will make future improvements easy should they be
required.
.S File Transfer Protocol
%6←Introduction%1
The %2File Transfer Protocol%1 (FTP) provides Dialnet hosts with a set of
commands for transmission of files among them.
Because we count on quite different systems using Dialnet, it is necessary
to establish a small set of essential commands and replies that are
implemented by all of them in order to make possible the communication
between any two sites. On top of this, additional commands are defined that
enchance data transfer between two similar hosts.
FTP commands consist of standard 8-bit ASCII strings. Any number appearing
in a command will always be decimal.
The interactions between the various parties in an FTP transaction may be
best described by the following diagram:
%7
.BEGIN NOFILL
__________ __________
| | Data | |
----->|(Output)|>---------->|(Input) |>--
! | | Channel(1) | | !
! | | | | !
! | | | | !
! | | Command | | ! _______
! | Server |<==========>| User |<======>| User|
! | Process| Channel(0) | Process| ! |_____|
∧ | | | | !
________ | | | | ! __________
| File | | | Data | | --->| File |
|System|<-<|(Input) |<----------<|(Output)|<----<| System |
|______| |________| Channel(2) |________| |________|
.END
%1
Under request from the user process, the user program establishes a
connection with the desired server. Channel 0 is employed for exchange of
commands and replies between the user and server programs. When a
connection is established, the server sends a "reply" consisting of a
greeting message (which can contain anything, such as system name, etc.).
At this point both sites must reach some agreement about the
characteristics of the flow of data between them so that the transferred
data is interpreted in the same way at both ends of the connection. This
is the purpose of the DATA command. The agreement may be renegotiated at
any time in which no data transmission is in progress. The user may then
issue service requests thru the command channel.
Data is transferred on the data channels. When the server receives a
request to retrieve a file, it tries to obtain the file and, if everything
goes right, it sends a positive reply on channel 0 and starts sending the
data on channel 1. Upon receipt of the reply, the user will start taking
packets from channel 1 and will eventually store the data in its file
system. When a store or append operations are requested it is the user
program which gets the file and sends it to the server thru channel 2.
After the request, the server is listening to this channel and when the
packets arrive, it will store the data in its file system.
Data transmission is terminated by any of the following reasons:
.BEGIN INDENT 10,10,10
- The receiver gets an end of file on that channel. This is the normal
termination for a successful data transfer.
- An interrupt has been issued on the data channel. Any data previously
received in that transmission is discarded.
- The command channel is closed. The command channel may be closed by the
server at any time, but it will typically do so only after a request from
the user who will send it when finished using the FTP service.
.END
.NEXT PAGE
%6←FTP Replies%1
The following pages contain a description of the commands available in the
Dialnet File Transfer Protocol and the corresponding set of replies.
It is strongly recommended that %2all%1 the commands be implemented, although
clearly not all have the same importance.
There are only four possible replies. In each of them the first item
identifies the reply. The second item is a list which contains a string
which in most cases is passed to the user without further processing. Hence,
there is a choice as toλthe amount of information to return in a reply.
The replies are:
.BEGIN INDENT 5,10,10
%2(OK (<optional-text>))%1
.BREAK
The command has been accepted as issued and
will cause the desired effect. If the command requires two replies, this
is the primary positive reply.
%2(DONE (<optional-text>))%1
.BREAK
This is the secondary reply for a data
transfer command whose primary reply was positive. It indicates that the
data transfer is finished.
%2(BUSY (<optional-text>))%1
.BREAK
The server cannot attend the request but if
you keep trying it may eventually give you the service.
%2(FAILED (<optional-text>))%1
.BREAK
You are losing with this command. The argument will tell the reason.
.END
.NEXT PAGE
%6←Access Control Commands%1
The following commands specify access control identifiers. Some sites
may not require them, but if issued they should be correct. When needed
it is the responsibility of the user program to make sure that they arrive
in the correct order. Because the server has the faculty to close the
connection at any time, it may very well do so after several unsuccessful
log-in trials.
I. (USER <user-id>)
With this command the user identifies himself to the server so that it is
granted access to its file system. Some sites might require this command to be
the first command thru the connection and may even require a complete
log-in sequence with a password and/or an account number. A new USER
command may be sent at any time, in which there is no data transmission,
to change the access control and/or accounting information. Transfer
parameters are unchanged by this command.
Replies:
.BEGIN INDENT 5,10,10
%2(OK)%1
.BREAK
The user has successfully logged into the foreign host. No
password is required.
%2(OK (PASSWORD?))%1
.BREAK
The <user-id> was accepted but a correct password is
required to continue the log-in process.
%2(BUSY (<reason>))%1
%2(FAILED (<reason>))%1
.END
.SKIP
.IF LINES<10 THEN NEXT PAGE;
II. (PASSWORD <password>)
The argument is a character string specifying the user's password.
Replies:
.BEGIN INDENT 5,10,10
%2(OK)%1
.BREAK
User log-in completed.
%2(OK (ACCOUNT?))%1
.BREAK
The <password> was accepted but an account specification
is required to continue the log-in process.
%2(FAILED (<reason>))%1
.END
.SKIP
.IF LINES<10 THEN NEXT PAGE;
III. (ACCOUNT <account>)
The argument is a string identifying the user's account.
Replies:
.BEGIN INDENT 5,10,10
%2(OK)%1
.BREAK
Even if the server has no accounting service this reply should be
sent in case a fixed sequence has been issued by the user.
%2(FAILED (<reason>))%1
.END
.SKIP
.IF LINES<10 THEN NEXT PAGE;
IV. (BYE)
The user sends this message before closing the connection, to say it is
going away.
Replies:
.BEGIN INDENT 5,10,10
%2(OK)%1
.END
.NEXT PAGE
%6←The DATA Command%1
V. (DATA <byte-size> <type> <structure>)
The systems that communicate by means of Dialnet may have different word
(byte) lengths, employ different data representations and structure their
stored data in various ways. To solve this problem we define some
standard default values of these parameters and employ the DATA command to
change them in cases in which the standards are not adequate. All users
of Dialnet must implement the defaults, that is, they must be able to send
and receive meaningful data in contiguous logical units of 8 bits, which
can be interpreted as standard ASCII characters and are always transferred
in groups delimited by end-of-file characters.
When a connection is first established, the server will assume that the
default values will be used and will be prepared to make the necessary
data conversions from his own to the default form when sending, and from
the default to its own when receiving.
Often user and server will be similar machines and converting the data to
the standard default form will be unnecessary. The DATA command allows a
user to tell which are the parameters that he wants the server to employ
on the data in order to minimize the user's data conversion effort. It
can be issued as many times as desired but not during a data transmission.
Of course, it can also be used to return to the standard default form.
All the arguments should be given, and precisely in the specified order.
They stand for:
.BEGIN INDENT 5,10,10
<byte-size> is a decimal number specifying the desired logical byte size,
i.e., starting with the first bit transmitted on the data channel, every
<byte-size> bits are a complete entity. The default byte size is 8.
<type> may be:
.END
.BEGIN INDENT 10,15,16
ASCII Data consist of a sequence of contiguous standard 8-bit ASCII
character. The end of a line of text is denoted by a sequence <CRLF>.
This is the default type.
EBCDIC Data consist of 8-bit EBCDIC characters. The end of a line of text
is denoted by a <NL> character.
IMAGE Data consist of a stream of contiguous bits that should be taken in
contiguous groups of size given by the value of <byte-size>. This type is
intended for efficient transmission between similar machines.
.END
.BEGIN INDENT 5,10,10
<structure> may be:
.END
.BEGIN INDENT 10,15,16
FILE File (no internal structure). The end of a file is marked by an
end-of-file packet.
RECORD The data is grouped in records delimited by an EOR (end of record)
marker. At the end of the file there is an end-of-file packet after the
last EOR.
.END
If a site receives and stores a file while certain parameter values are
active and is later requested to return that file using the same values,
the input and output copies should be identical. Also we must require that
any transformation suffered by a file during the process of storing it do
not affect the contents of that file if output in another form.
Replies:
.BEGIN INDENT 5,10,10
%2(OK)%1
.BREAK
Good, the server agrees.
%2(BUSY (<reason>))%1
.BREAK
You are not allowed to change the transfer parameters now.
%2(FAILED (<reason>))%1
.BREAK
The server may not have implemented one or several of the
parameter values specified by the arguments, or it can accept each of them
in some combination but not the three together as required in the command
or the arguments are not in the correct order, etc.
.END
.NEXT PAGE
%6←FTP Service Commands%1
VI. (RETRIEVE <for-path-name>)
This command tells the server to send the file specified by
<for-path-name> to the user. Upon receiving it, the output side of the
server's program should look for this file in the server's file system.
Then it will report the result of the lookup operation (so that the user's
program can be informed) and, if successful, will start transmitting. At
the end, a report about the result of the transfer operation will also be
emitted.
Primary replies:
.BEGIN INDENT 5,10,10
%2(OK (<text>))%1
.BREAK
The lookup succeeded and the server has started sending the file.
%2(BUSY (<reason>))
(FAILED (<reason>))%1
.END
Secondary replies:
.BEGIN INDENT 5,10,10
%2(DONE (<text>))%1
.BREAK
The transfer is finished and the data channel closed.
%2(STOPPED (<text>))%1
.BREAK
Channel 1 was closed before an end-of-file had arrived.
The part of the file that had already been transmitted (if any) will not
be saved, i.e. the RETRIEVE command will not have any effect.
.END
.SKIP
.IF LINES<10 THEN NEXT PAGE;
VII. (STORE <for-path-name>)
The server should open a file named <for-path-name> and store in it the
data that the user will send. If a file with that name already exists at
the server site it will be overwritten, otherwise the server should create
it.
Primary replies:
.BEGIN INDENT 5,10,10
%2(OK (<text>))%1
.BREAK
The file has been found or created. The server is ready to
receive the data thru channel 2.
%2(BUSY (<reason>))
(FAILED (<reason>))%1
.END
Secondary replies:
.BEGIN INDENT 5,10,10
%2(DONE (<text>))%1
.BREAK
The transfer is finished (an end-of-file has been
received). The file is closed and so is data channel 2.
%2(STOPPED (<text>))%1
.BREAK
Channel 2 closed before an end-of-file arrived. The
part of the file that had already been received (if any) will not be
saved. The STORE command will not have any effect.
.END
.SKIP
.IF LINES<10 THEN NEXT PAGE;
VIII. (APPEND <for-path-name>)
This command tells the server to open the file specified by
<for-path-name> for input and append to it the data that the user will
send thru channel 2. If no file exists with that name this command will
have the effect of a STORE command.
Primary replies:
.BEGIN INDENT 5,10,10
%2(OK (<text>))%1
.BREAK
The file has been found or created.
%2(BUSY (<reason>))
(FAILED (<reason>))%1
Secondary replies:
%2(DONE (<text>))%1
.BREAK
The transfer is finished (an end-of-file has
been received). The file is closed and so is data channel 2.
%2(STOPPED (<text>))%1
.BREAK
Channel 2 has been closed before an end-of-file has arrived. The part of the file
that had already been received (if any) will not be saved. The APPEND
command will not have any effect.
.END
.SKIP
.IF LINES<10 THEN NEXT PAGE;
IX. (ABORT)
This command tells the server that the file transfer requested by the
previous command has been cancelled. For that purpose an interrupt packet
is sent to the server on the data channel. Because the server was
attending that channel, it will recognize the packet, terminate any data
transmission or reception and turn its attention to the command channel.
Any data received so far will be discarded. The previous command will have
no effect on the files of either the user or the server. Had the transfer
already been completed and the data channel closed, the receiver would
have already closed the file in its file system and no abortion would be
possible.
Only file transfers can be aborted because there is no control on the
other services from the very first moment in which the corresponding
command is issued.
Replies:
.BEGIN INDENT 5,10,10
%2(OK)
%2(FAILED (<reason>))%1
.END
.SKIP
.IF LINES<10 THEN NEXT PAGE;
X. (RENAME <for-path-name1> TO <for-path-name2>)
The server is instructed to change the name of <for-path-name1> to
<for-path-name2>.
Replies:
.BEGIN INDENT 5,10,10
%2(OK)
(BUSY (<reason>))
%2(FAILED (<reason>))%1
.END
.SKIP
.IF LINES<10 THEN NEXT PAGE;
XI. (DELETE <for-path-name>)
The server is instructed to delete the file specified by <for-path-name>.
Replies:
.BEGIN INDENT 5,10,10
%2(OK)%1
.BREAK
The file has been deleted.
%2(BUSY (<reason>))
(FAILED (<reason>))%1
.END
.SKIP
.IF LINES<10 THEN NEXT PAGE;
XI. (DIRECTORY <for-dir-name>)
This command asks the server for a list of the files in the directory
specified by <for-dir-name>. If no argument is given a list of the files
in the log-in directory should be sent. The information will be contained
in the reply (sent thru the command channel).
Replies:
.BEGIN INDENT 5,10,10
%2(OK <file-list>)%1
.BREAK
<file-list> is the requested list of files. It should be
passed directly to the human user.
%2(FAILED (<reason>))%1
.END
.SKIP
.IF LINES<10 THEN NEXT PAGE;
XII. (STATUS)
With this command the user asks for whatever information the server may
want to send him. It may be issued at any time. The information will be
sent as a reply on channel 0 (the command channel!) and is intended
exclusively for human users.
Replies:
.BEGIN INDENT 5,10,10
%2(OK <information-list>))%1
.BREAK
The contents of the <information-list> should be
directly sent to the human user for its interpretation. This is the only
legal reply.
.END
.S Glossary
.BEGIN INDENT 5,10,10
ACKNOWLEDGEMENT -- an 8.-bit quantity which specifies the packet sequence
number of the highest consecutive packet which has been successfully
received. An acknowledgement implies that all packets with lower sequence
numbers have been received as well.
BYTE -- an 8.-bit quantity. While %2Dialnet%1 transmissions are to be
considered as a bit stream, this concept is convenient to use for many
reasons.
BYTE SIZE -- this refers to the byte size of data as seen by the host
computer. All %2Dialnet%1 transmissions should be considered bit stream
transmissions sent in units of 8.-bit bytes.
CHANNEL -- a 4.-bit quantity identifying which data stream this packet
belongs to. Channels have no meaning to the host-host protocol, only to
higher level protocols. Channel 0 is the channel normally used.
CHECKSUM -- a 16.-bit quantity containing a packet checksum, used in error
detection.
CONNECTION -- a logical connection between two processes. Connections are
bidirectional.
DATA -- an arbitrary amount of data which is either used as arguments in
the Host-Host protocol or as data to be passed to a process utilizing
%2Dialnet%1.
DATA COUNT -- a 8.-bit quantity indicating how many bytes are in the data
field of the packet after the first data byte.
%2Dialnet%1 -- a communications protocol for data transmission over
standard phone lines. This term also refers informally to the set of
hosts which implement %2Dialnet%1.
EOP -- a marker used to indicate end of packet. EOP consists of ASCII DLE
(220) followed by ETX (202). It is a violation of packet framing for a
packet to end with anything other than an EOP. A packet is not completely
received until this code has been received. Note that the 200 bit must be
set for an EOP to be recognized as such.
HOST -- a system with %2Dialnet%1-compatible modems and
%2Dialnet%1-support software which knows the telephone number of at least
one other host.
HOST-HOST PROTOCOL -- The protocol which provides for compatible
communication between two processes running on (probably) dissimilar
hosts.
LINE TRANSMISSION PROTOCOL -- The protocol which provides for error free
transmission between two hosts with a common modem which use the Host-Host
protocol.
OPCODE -- a %2Dialnet%1 host-host protocol operation code.
PACKET -- a logical unit of data transmitted over a %2Dialnet%1 link. The
packet is the elementary unit of %2Dialnet%1 transmissions. A packet is
basically data with a header and trailer.
PACKET FRAMING -- a technique used in the line transmission protocol which
requires that all packets start with an SOP marker and end with an EOP
marker. A packet must be properly framed for it to be considered to have
been received correctly. Framing errors cause the packet in progress and
all succeeding data to be discarded until framing is restored.
PACKET NUMBER -- an 5.-bit quantity which uniquely identifies a packet at
a given point in time. This is used to identify packets if necessary in
error recovery. Packet numbers may be recycled after both hosts have
agreed that the packet associated with this packet number has been
correctly sent and received.
PROCESS -- an entity utilizing %2Dialnet%1. %2Dialnet%1 traffic consists
of communications between processes.
PROCESS ID -- an 8.-byte ASCII string which uniquely identifies the
process. See the ICP and higher-level protocols for process-ID
conventions.
SERVER -- the initially passive process in a connection.
SOP -- a marker used to indicate start of packet. SOP consists of ASCII
DLE (220) followed by STX (203). It is a violation of packet framing for
a packet to begin with anything other than an SOP. Any data received when
an SOP is expected should be discarded. Note that the 200 bit must be set
for an SOP to be recognized as such.
TIMEOUT -- A delay time for a specified action. If the desired action
does not occur within a specified time, a "timeout" action is taken.
USER -- the initially active process in a connection.
WINDOW -- The margin for packets vs. their acknowledgements so that
acknowledgements do not have to be completely synchronous with packets.
WINDOW SIZE -- The maximum number of unacknowledged packets which may be
pending at any time. This is similar to what the Arpanet calls "message
allocation".
.END